This document is designed to promote a greater understanding of FileMaker Server and help database administrators provide the best possible service to their customers: the database users. The information provided comes from internal FileMaker employees, FileMaker system engineers working in the field, and FileMaker Solutions Alliance partners. The advice is therefore a healthy mix of both internal knowledge and real-world expertise. This document does not, however, cover in entirety the best practices for the operating system, system backups, and enterprise networking.

Database administrators, IT/IS professionals, and users want their database systems to operate robustly and safely. Users rely on the data in database files for a wide variety of management purposes, irrespective of the size of the enterprise. Correct, optimal configuration of FileMaker Server is an integral part of providing that type of reliability. And while it's beyond the scope of this paper, proper architectural design of the multi-user files holding the data is the other integral part. Without both proper design and proper configuration and deployment, a safe, robust, reliable system won't exist.

Because FileMaker Pro is such an easy-to-use application and, more times than not, the database administrator has grown to that position without a strong IT background, the FileMaker Server tends to be treated as a load-and-go solution. The opposite extreme is that the database administrator has a strong IT background and knows little about FileMaker Pro, yet he's been tasked with setting it up; this can result in the server being treated like an enterprise server. FileMaker Pro is easy and it can serve the enterprise, but performance, reliability, and cost are at stake when it's configured improperly. I'll examine these extremes separately.

The workgroup administrator
When a FileMaker Pro database has grown in a workgroup to the point that the organization needs FileMaker Server, the person who developed that database usually becomes the database server administrator. Often, the hardware allotted for this job is inadequate, the operating system is unstable or inappropriate, and the backup routine is abysmal. If you are this person, take heart! You learned to use FileMaker Pro to create the database that's being used to help your organization work more efficiently. Learning to use FileMaker Server will likely be far easier than creating that database. Perhaps the most difficult part of the job will be to secure the appropriate server hardware and operating system to get the job done right. Convince the appropriate people that the data is priceless, and the cost of securing that data should seem negligible.

The trained professional administrator
Fortunately, those who are storing valuable data have come forward for your help. It should also be a comfort to know that they've been using a tool to capture data that will save on IT costs, since FileMaker Server tends to be a "near lights out" solution. Setting up a FileMaker Server may be the easiest server installation you'll have to do in your career. Just one word of caution: Don't treat FileMaker Server quite like an average server. Though there are some similarities and you'll want to provide adequate hardware, a $20,000 quad-processor with 1GB of RAM like you may be accustomed to for servers is a waste of money for FileMaker Server.

Hardware
As everyone knows, there's a difference between the stated minimums and the desirable minimums. FileMaker Server's minimum system requirements are as follows:

Windows:

• Pentium 133MHz
• 64MB RAM for NT
• 128MB RAM for 2000
• Windows NT 4.0 (SP4) or Windows 2000

• Apple G3 (excluding G3 upgrade cards)
• 256 RAM (previously recommended only 128MB RAM)
• Mac OS X

• Power Macintosh
• 256 RAM (previously recommended only 32MB RAM)
• Mac OS 8.6 to 9.1

• Pentium 133MHz
• 64MB RAM
• RedHat Linux 6.2 or 7.0

• Build the machine from the ground up yourself. Don't trust your valuable data to an operating system loaded by the hardware provider. These installations are notoriously problematic. Doing a custom installation of the server OS provides a system loaded with the bare minimum without the difficulty of removing items.
  
  
• Partition the drives to provide maximum reliability. Separate the operating system from the FileMaker data if at all possible. Installing the operating system using a RAID 0 configuration separated from the FileMaker data placed in a RAID 5 configuration is an optimal balance of speed and reliability. Also, on a Linux installation, putting the /var/log path in its own partition is desirable. This way, if there are any logs growing out of control, they will only fill that partition, leaving the operating system and FileMaker data files unharmed.
  
  
• Turn off file sharing and other unused services. File sharing is the ability to access files on a remote network device. What FileMaker Server does isn't file sharing; it's data sharing. File sharing uses a good deal of I/O resources, the same resources on which FileMaker Server relies. Therefore, any type of file sharing will reduce performance of the FileMaker Server. Making the database files available via file sharing is not only a performance issue but also a security issue. If there's a way for someone to get access to the physical FileMaker files, then there's the possibility for a security breach. One of the easiest ways to lessen this threat is to be sure users can only access the data by opening the database and navigating the "Open Remote Database" or "Hosts" dialog.
  
  
• Keep the FileMaker database files local on the server. Although it may seem natural to place FileMaker data files on network directories, this is a bad idea. The most important factor for FileMaker's performance will be a fast and clean I/O to the disk files. Thus, reading data and writing updates to a local disk is imperative. If the FileMaker files are on a network drive, then any data updates first have to climb down the OSI model network layers, across a network full of competing packets, and back up the OSI ladder at the target volume, and then finally be committed through the drive sub-system there to the files. Even on the best network, this process is orders of magnitude slower than a simple local write and adds quite a few variables, potentially affecting stability as well as speed. Additionally, the target drive is, by definition, a shared volume. Therefore, all of the issues mentioned previously regarding security and stability in file sharing would apply.
  
  
• Turn off unused network protocols. FileMaker Server can communicate over TCP/IP, IPX/SPX, and AppleTalk. The Red Hat Linux version and the Mac OS X version only use TCP/IP. Use only TCP/IP networking; additionally it's the only protocol available in a cross-platform network for FileMaker Server 5.5. The bottom line is that the server will have to devote less overhead if it's only using one protocol rather than two or three, so reduce the overhead by specifying the protocols it will use.
  
  
• Reduce the number of guests. Determine how many concurrent guests will be connecting to your FileMaker Server, add 10 percent for good measure, and set it at that. Although you could host to up to 250 users, each user takes up worker threads on the computer, increasing overhead. Reducing the overhead significantly improves performance.
  
  
• Reduce the number of files. Worker threads are also maintained for each possible file. So, reducing the number of files to the number actually being hosted and leaving 10 percent for growth will use less overhead. Changing either of these numbers later isn't a difficult task, but it does require that the FileMaker Server service/daemon/application be restarted.
  
  
• Reduce the computer's extraneous work. Often people will set up a server beautifully -- all the right settings, low overhead, etc. -- but leave the machine running a processor-intensive screen saver or virus scanner. Reducing the resolution and color depth of the server machine can save some processor work. This screen is not meant for entertainment, so set the screen to just go blank -- there's little processing being done on a blank screen. Checking for viruses is important, but don't steal valuable processor cycles on continual checking. If this machine is configured not to do file sharing, it won't need continual checking. Schedule regular scans during off-peak hours.
• Don't use energy saving software. This is a server you're dealing with. You really don't want it to go to sleep, waiting for a request to come in to wake it. Don't let the hard drive or the system sleep. At most, let the screen power down.
  
  
• Restart the computer regularly. Despite claims that operating systems are getting more reliable, a regular restart is still a good idea. Operating system developers tend to release fixes to their software to fix memory leaks and other similar problems. Restarting the server occasionally can be beneficial. If you find there are any memory leaks occurring through the use of the operating system's performance monitors, track those leaks down and repair or report them to increase stability.
  
  
• Tweak FileMaker Server's cache settings. FileMaker Server has its own built-in cache to allow fast communication to memory rather than making every transaction communicate with the hard drive. This cache has a maximum size of 40MB. There's a certain amount of overhead involved in checking the cache for data prior to going to the hard drive. Therefore, you can gain some performance by properly tuning the cache. Using a gauge provided by FileMaker Server, you can determine the Cache Hit percentage. The Cache Hits should maintain around a 95 percent hit rate in the production environment. If it's regularly less than this, increase the cache size. If much more, try reducing the cache size slightly. A good rule of thumb is to set the server cache to 5 percent of the total size of database files hosted. This is only a starting point from which you can make adjustments.

• The FileMaker Server application should always be the front-most application. This means that the upper-right corner of the screen should say FileMaker Server, not Finder. If the desktop was clicked, then the Finder will take priority and slow the server tremendously. This goes for other applications, as well, not just the Finder. In fact, any interaction with something other than the server will slow it down. Legend has it that a user's FileMaker Server "crashed." When the administrator investigated the server, he found that a book had fallen from a shelf landing on the mouse. The mouse-down event took control of the system, not allowing any processor sharing for the server to handle requests.
  
  
• Set the server application to "Maximize Performance." In FileMaker Server's preferences (figure 1), an option exists under Administration that says "Maximize performance." This option reduces the amount of CPU available for other applications. As previously mentioned, this machine should be dedicated to FileMaker Server, so this won't be detrimental to the system -- in fact, it will help in the primary purpose of the system.
  
  
• Minimize the extensions being used. A good place to start is the basic extensions needed by the operating system. This can be set up with Extensions Manager. Build the "necessary" list from there. Turn off all energy saving settings as well as any virus checking. These are unnecessary, yet very costly when it comes to performance.
  
  
• Set the memory appropriately. Setting the amount of memory an application is given to use is a concept unique to Mac. In the troubleshooting of a Mac-based application, the amount of memory given to the application is often increased, which makes the application work better. This isn't the case with FileMaker Server after a point. FileMaker Server is a relatively small application, streamlined for the purpose of sharing data. When FileMaker Server is installed, it's given a minimum amount of memory requirement of 4MB (4,096KB) and a preferred amount of 8MB (8,192KB). The memory requirement consists of a combination of the memory needed for the application and the requested cache size. Therefore, a change in the cache size setting will result in a dialog requesting a change in the application memory. Allow that change to be made (and verify that it was made in the Get Info dialog). Increasing the memory beyond the recommendation won't help performance. In fact, it may harm performance due to the increased overhead of the memory given to the application.
  
  
• Don't use virtual memory. Virtual memory uses the hard drive as if it were physical memory for the computer; therefore, it's I/O-intensive. As stated earlier, FileMaker Server uses the hard drive extensively. Adding extensive use of virtual memory will severely slow the performance of the FileMaker Server. However, several administrators have indicated that performance increased dramatically under certain conditions when virtual memory was turned on and set to only 1MB over the physical memory size. Keeping the setting at only 1MB over physical memory size ensures that the virtual memory is not actually being used.

• Optimize for Background services. In the System Properties, under the Advanced tab, under "Performance Options...", choose Optimize performance for: "Background services." This makes the operating system give priority to the services, including FileMaker Server.
• Optimize for network throughput. For the properties for each LAN connection, ensure that under the properties for "File and Printer Sharing for Microsoft Networks," Server Optimization is set to "Maximize data throughput for network applications."
• Set the paging size and location appropriately. In the System Properties, under the Advanced tab, under "Performance Options...", under Virtual memory, make sure the paging is set to a reasonable size (just over the size of RAM is ideal) and not too large. Also make sure the entire paging file is on one drive and that the drive is a fast drive, preferably on a different drive/controller than the FileMaker data.

1. FMS "pauses," meaning the cache is flushed, writing all data to the disk.
2. FMS releases the files so it's no longer in control of them.
3. FMS copies the files to the specific backup location.
4. After the copy is complete, FMS resumes, meaning it reattaches to the files and starts replying to the clients again.